II Something
by Clark Hugh Stiles
November 14, 2001 

Analysis -- Someday I'm going to get a disk drive for this iMac and hunt up all my old stuff, rather than reinvent the wheel all the time. I can't even find my copy of Gary Little's book on programming for ProDOS. It may be in the attic, which is weird, because all the other Apple II ProDOS programming books are right here. 

To make it as operable as possible (without a resort to an AppleSoft frontend big as Montana) this will be a binary routine for the most part. I'm still trying to find out what JMP leads to the HGR command in AppleSoft (that clears the range of memory to be used), which would save some time. The eventual AppleSoft BASIC program will do little more than start up 80 columns, print a few onscreen pointers, clear the RAM, and BRUN the binary file. I plan to use binary even for the keyboard input routines. 

Why, oh why? Hey, humans can drive Vipers, but Jay Leno still works on old cars. 

While not based on the one in Don Worth and Pieter Lechner's classic Beneath Apple ProDOS (too bad, that would have been a timesaver) this program will use the same BLOCK_READ and BLOCK_WRITE calls. Before it reads or write any blocks, it will do an ONLINE call, fish out and store the valid slot / drive info, and punch a few pieces of data into the appropriate places on the screen. For one thing, the listing of the block -- all 512 bytes of it -- will have to be displayed 32 bytes (2 characters each) across by 16 lines down, meaning the 80 column screen will be used. 

In the old Beagle Bros "ProByter" program the 40 column screen use meant that the disk block in memory was displayed one half at a time. But there were (I think) four different displays for the data -- CATALOG, Hex, and a couple of different ASCII displays. The edit mode was determined by the display, making it quite handy. 

I can't find the "ProByter" manual, but I did find the "fun with the lock byte" and some other pages, photocopied onto one 8.5x11 sheet, and tucked in Assembly Lines. The CATALOG explanation is on one side of this copy, and on the remaining face an explanation of the way ProDOS stores the date and time. All hail the Beagle Bros! 

I'm building these routines a bit at a time. The plan is to build all of them in relocatable chunks, mostly because I don't have the means to move my old Bredon-built assembler, and don't have the experience with the one I've got on the Bernie volume. Also, the half hour Bernie time limit is, well, limiting. 

Here's a relocatable routine that goes through the data returned from the ONLINE call, and stores the slot / drive info in the program's buffer area. Only valid device numbers are stored. Byte $2303 is used to keep track of the number of valid devices. With a little more work than I care to embark on, this could print the volume names. When the program is complete you'll have to put on your propeller beany and enjoy the display as it is. 

As before, you launch BASIC.SYSTEM, then just type what you see, apart from the last two lines. Those are the result code. NOTE that there's a space between the exclamation point prompt and the other stuff, except where it says !300. 

Program Listing: 
CALL-151
*!
!300:LDX #$00
! PHX
! PLX
! LDA 2200,X
! TAY
! TXA
! CLC
! ADC #$10
! BCS 320
! PHA
! TYA
! AND #$0F
! BEQ 303
! TYA
! INC 2303
! LDY 2303
! STA 2303,Y
! BNE 303
![return]
*300.31F
*0300:A2 00 DA FA BD 00 22 A8 8A 18 69 10 B0 12 48 98
*0310:29 0F F0 EF 98 EE 03 23 AC 03 23 99 03 23 D0 E3 
End of Program Listing. 

This code does you no good without the ONLINE code, but hey, it's only 32 bytes long. Take a look at the (I think) purloined and altered Roger Wagner routine for simulating an ONLINE call found in the Disk.Menu program, if you can figure out where it begins and ends. 

Speaking of figuring out where things begin and end, I'll point out right now that this project, though small, will be done in small segments, and out of sequence. That's one advantage to relocatable code. In the ML world (at least, in the 8-bit ML world) those instructions starting with B (BEQ, BNE, BCS, some others) only work within a 256 byte range called a memory page -- for example, $0300.03FF -- but while they can jump forward or back, they can't go beyond the boundaries. 

What this means to you is, the relocatability is limited. The routine can't lay across a boundary, or the branching (hence the letter B) will go somewhere other than what was intended. And that leads to unpredictable results. In a professional assembler / linker package, those are not as easy to see perhaps, but they will error out during assembly. 

II Infinitum! 